Type Inference for Sublinear Space Functional Programming

We consider programming language aspects of algorithms that operate on data too large to fit into memory. In previous work we have introduced IntML, a functional programming language with primitives that support the implementation of such algorithms. We have shown that IntML can express all LOGSPACE functions but have left open the question how easy it is in practice to program typical LOGSPACE algorithms in IntML. In this paper we develop algorithms for IntML type inference. We show that with type inference one can handle programs that could not be reasonably manipulated by hand. We do so by implementing in IntML a typical LOGSPACE algorithm, a test for acyclicity of undirected graphs. Thus we show that with type inference IntML can express typical algorithmic patterns of LOGSPACE easily and in a natural way. The study of algorithms operating on data too large to fit into memory has a long tradition in complexity theory; it comprises in particular the complexity classes LOGSPACE and NLOGSPACE of algorithms with logarithmic space usage. By comparison, questions about the programming language aspects of these classes have received little study. What is a good way of programming LOGSPACE algorithms in, say, a functional language? How should one represent values that do not fit in memory and that can only be accessed piece by piece from some external store, such as the input and output of a LOGSPACE function? To approach such questions, we have recently introduced the functional programming language IntML with support for working with externally stored data [6]. As a first test of the expressive power of IntML, we have shown that each LOGSPACE-function can be expressed in IntML. However, since this result is obtained by encoding Turing Machines, it is not very informative about whether or not it is possible to program such functions easily and in a natural way. In this paper we ask how easy it is to express well-known algorithms with logarithmic space usage in IntML. We take a typical LOGSPACE-algorithm, Cook & McKenzie’s test for acyclicity in undirected graphs [5], and show that it can be programmed in IntML in a natural way. The main contribution of this paper is the development of type inference algorithms for IntML, which make programming such typical LOGSPACE-algorithms in IntML practical. Type inference is particularly important, as the IntML type system allows one to ? The author is partially supported by PRIN project “CONCERTO” and FIRB grant RBIN04M8S8, “Intern. Inst. for Applicable Math.” ?? Part of this work was carried out while the author was supported by the Institute of Advanced Studies at the University of Bologna. read off bounds on the space-usage of programs directly from a typing derivation, which means that writing out all type information fully will soon become unmanageable. In this paper we show that much of this information can be reconstructed automatically using a type inference algorithm. While type inference has been shown to be possible for languages capturing PTIME [2, 4], in the context of languages for sublinear space the possibility of type inference is novel. 1 Programming with Bidirectional Data Flow The definition of IntML can be summarised as follows: start with a standard functional programming language and extend it with primitives for writing programs with bidirectional data flow. Bidirectional data flow is an important property of computation with external data that may not fit into memory. An input that is too large to be stored cannot be read all at once; it can only be queried piece-by-piece during the course of the computation. Thus, information flows not just from the input to a program but in the form of queries also in the opposite direction. We believe that providing a good account for this kind bidirectional data flow should be a central goal in the construction of programming languages for computation with external data. The construction of IntML starts with a very simple language having just polynomial types α, 1, A + A and A × A. It has the usual terms for these types and also a loop construct for possibly nonterminating iteration. More details are not needed for now (but they appear below). Richer languages would be possible, but this one is suitable for capturing LOGSPACE. We consider this language as a model of computation with unidirectional data flow. A term c:A ` f : B represents a function from values of type A to values of type B, which can be computed by substituting an input for c and subsequent reduction. Suppose now that there is some externally stored data that can be queried pieceby-piece. Its interface is given by a pair of types (X−, X). The type X− consists of the queries that may be sent to the datum and the type X encodes possible answers. For example, to represent binary words that can be queried character-by-character, one may take X− to be a type representing the character positions in the word, e.g. X− = (1 + 1) × · · · × (1 + 1), and one may take X to be the type (1 + 1) that represents the two possible characters. We can note here already that the size of the values of these types X− and X is logarithmic in the length of the words being represented. A program with bidirectional data flow can now be considered as a message passing node with a number of input and output wires, e.g. Fig. 1. Each wire has a direction and is labelled with a pair of types X = (X−, X). The intention is that values of type X can flow as messages along wires in the direction of the wire, and values of type X− can flow in the opposite direction, see Fig. 2. Message passing nodes are stateless and may react to messages arriving (one at a time) at one of the wires connected to them. When a message arrives, the node uses it as input in order to compute an output message that it may then pass along one of the wires connected to it. We emphasise that wires are bidirectional and that messages can be passed in both directions on all wires. The direction of the wire merely determines which type of message can be passed